Hello, it seems the summer heat has finally subsided, and we have not had to run our AC units the whole week. We mentioned earlier we have had Dominik in for a testing week, and we are happy to say that he is quite qualified for a position here, so will be remaining with us. Tom has also joined us, moving here from the Republic of Ireland, and has been getting settled in working through a lot of the small unassigned tasks. It also seems most of us are back from our vacations, so the pace is picking up again. Most of the work this week has been on the unentertaining spectrum, with a lot of internal reworking and refactoring going on. A lot commits related to fixing our compilation after the move to C++17. Many of the GUI and input action functions were broken (such as rebinding keys, switch map editor tabs, setting combinator filters), so its been a team effort to fix these as they are found. Hopefully not many will slip through the cracks and into release.
Hello, as you could get from the caption, the work during the week was pretty frustrating at times, but the more rewarding it felt when the problems were finally fixed. This time I decided to give you another peek to our different kind of bug battles.
AMD Ryzen crashes (Klonan) The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution. A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified. Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers. So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.
Hello, we have gathered here today to talk about a new quality of life feature coming with 2.0.
Hi all, what a week. Let's see what has happened. The Launch Week The game launch at Steam has obviously been a highlight of the week (well not just the week=)). However quite a few other "launches" have happened as well. As for the game, together with Steam launch we have launched the game at Humble Store. Based on how this goes we might add a few other popular retail sites (i.e. GOG, Green Man Gaming). Prior to the appearance of the Game on Steam, we came up with the 0.12.24 (imho a magical release number) which fixed a couple of last minute bugs. This is the version available at Steam. Outside of the digital world, there have been quite some news as well. Kovarex's son Robin has been born on Monday early in the morning. As Kovarex reported, the whole process went quite smoothly and fast. The family is back at home from hospital already. And finally, a baby girl called Ema has been born to our artist Vaclav. This has happened some time ago already, however there were quite a few complications and only this week Vaclav has returned to the office. All is fine by now as well with his family. We were thinking of posting some pictures of the babies, but as kovarex rightly noted "All babies look the same". So there is not much point=) Gameplay Trailer You have probably noticed the homepage layout has been changed. This is due to the release of our new Gameplay trailer. The Factorio Trailer is focused on giving an impression of the game. Without giving too much explanations of what is going on. Basically it goes for the WOW EFFECT. With the Gameplay Trailer our goal was to introduce the real aspects of the game to new players in a short video (well still keeping a bit of a wow effect=)). Show how the game actually looks, how player progresses in the game, how some common UI work, etc. Albert, Robert and others have poured many, many hours to the video. From the comments on Youtube it seems that it was more than worth it. Thank you Yesterday was pretty intense. Fixing last minute issues at our website, tweaking the Steam page, finishing the Factorio guide (see below), putting everything together, etc. Finally at 8 p.m. we have semi-automatically launched the game. Huge relief has replaced the frantic preparations. Everybody, except for Albert who went for vacation, was in the office. There was a bit of champaign and positive atmosphere. This got even stronger after a while when positive reviews started to pour in, Steam in-game counter kept going up and discussion at Steam page kicked off. Months of preparation culminated during that evening. After the launch we just relaxed and basically watched what was happening. And it was great to see the communnity engage so actively in promoting the game. So it feels more than appropriate to use this section for a big THANK YOU to you guys for all the support. It is difficult to capture everything, but I will try to list the imho most important stuff (I am a methodical type after all=)). So thank you, especially for: Awesome reviews. At this moment there are 630 reviews with rating of 99%. There is literally 2 "not recommended" reviews. That is mind blowing. Makes it a challenge to stay "with our feet on the ground"=) Support at reddit. The new Factorio Gameplay Trailer link has stayed at the top of r/Games for nearly full day. Heck, it seems that we have received as much exposure as highly anticipated Superhot. Spreading the word to your friends, youtubers, etc. Helping out new users at Steam discussions, Reddit, our forums etc. Factorio guide In one of the previous releases of FFF, we have mentioned a new third party documentation project called Factorio Strategy Guide. There has been some more development regarding this one. The result is that we (Wube Software) have bought the guide from the original author (Xterminator). We have turned the original .pdf document into a free online guide. Albert has spent his last "finishing" hours, before going for a well-deserved vacation, polishing this online document. This is linked from the Steam page as well. The guide should be considered to be very much a work in progress. There are many things that we plan to improve - phrasing, screenshots, general consistency. However we feel it could be of a good value for new players in the current state. That is why we pushed to have it ready for Steam release. There is a chance of integrating this one with Wiki in the future for instance. However at the moment this feels like the most comprehensive introductory resource into the game there is (apart from messing with the game yourself). Lua API documentation There has been one more update in the documentation. This time aimed at the modders community. The Lua API documentation at the wiki has always been a bit messy, not properly updated and often confusing. Couple of weeks ago, Oxyd and Rseding have finished a resolute mini project of making the Lua API documentation autogenerate from the source code. So basically the function bindings in the code are annotated with special-formatted comments (imagine something like java Doxygen) and based on this a comprehensive reference is then generated. You can checkout the result at the Lua API doc page. We will link this website from some appropriate place soon. Another great advantage of this approach is that we can keep clear separation of documentation for different versions. The only drawback is that the feedback for the documentation is now more cumbersome. If you find something that could be improved, sending us an email is probably the best option at the moment. We might make a new topic for this in the modding subforum if necessary. Funny Stats Last couple of days and hours before the Steam release there has been an escalation of sales at our webpage. That was to be expected - people were taking advantage of cheaper price before Steam launch. It was also expected for sales to drop after the release. Still it is rather funny to watch the hourly sales stats from yesterday. Life goes on So this is it. A hectic week is over. The game is launched and it seems to be doing really well. Let's see how it goes=) I have a feeling that our support department (Scott=)) has some rought times ahead. Anyway, Monday seems like a good opportunity to "get back down to Earth" and continue in the 0.13 development, which has suffered a bit in the past two weeks. As usual you can post your comment at our forums.
Factorio Nomenclature Abregado Today I want to discuss some common problems that we see in video games. Inconsistent Terminology When I asked out loud "So what is an Intermediate Product anyway?", I got a similar reaction as when someone mentions The Berlin Interpretation at a rougelike convention. So what is an Intermediate Product? Well it is a product that is used only as an ingredient for something else. No, that's not right because Science Packs are not used in any recipe. So what then, Intermediate products are just things that you can use Productivity Modules on? Perhaps they are simply items that can be found in the Intermediate Crafting menu. Then are they not Intermediate Recipes? To give another example, answer these questions: Name the action a player performs when they add an entity to the world? Name the action a player performs when they remove an entity from the world? Name the action a player performs when they add a ghost entity to the world? Name the action a robot performs when they add an entity to the world? Name the action a robot performs when they remove an entity from the world? Here are a few situations where the game displays your possible answers: A player builds. A player mines entities. Robots repair and build entities, but wait… the player places buildings and builds ghosts? But here Robots are constructing machines. Here the robots are deconstructing items! This leads into a discussion about what is an item and what are entities, and that discussion leads us into the next point... Internal nomenclature leaking out During game development it is very common to use internal names to refer to mechanics, items, or characters. It does not feel like such a big deal, and many early access games simply ignore the problem completely. I'm not going to point any fingers, but if you look you will find some examples. Oh wait, here is some from your favourite early access game! Internally, things that exist on a surface in the game are called entities. All these items are capsules internally, but only 5 of them are actually labelled as capsules. Really, these should be categorised by how players use them, and indeed there is an attempt to do so. Remotes are items used to trigger an effect, Grenades are things you throw... but why is the Poison Capsule not called a gas grenade? There are more inconsistencies but to keep this article reasonably not-short, I will let you find the others yourself (and to save something for a future FFF about Tooltips). Why change? You might be thinking that this is not a big problem. Some others might be thinking that the problem is too pervasive to bother changing. There are a few reasons why it is important, the first, and most important of which is our quality mindset; everyone on the team here wants the game to be as great as possible. Next we should see this increase the quality of the translations. A translation is only as good as its source, and having a consistent usage of words can go a long way to helping the translators do better work. The effect of this can be increased by providing a dictionary of important words to the translators so they can be sure to always use the same term in all places. Since we are also working on a guided experience (Campaign), this would also help us give much clearer instructions to the player. An example of confusion here would be if one quest said "Place a chest" and another said "Place the item in the chest". The player needs to read the entire quest caption (probably twice), and can never build up a mental map of our language. This leads to the player spending more mental energy (cognitive load) while playing the game. Changing this to "Build a chest" and being consistent, allows the player to create mental shortcuts, meaning the quest tasks require less effort to understand. Finally, consistency in terminology will help new players, and I don't just mean sub-1 hour playtime players. Factorio is a 'Big Game' and players are encountering new items, entities, concepts, and text for a long time. How many hours did you play before you discovered this helpful trick, or this one? How to change? We could make the vocabulary consistent with what the current player base uses. This option sounds pretty good until I started asking people questions similar to those I asked you at the beginning of the article. Here are another two as a refresher: Where do biters come from? I come in 7 colors, what am I? The only wrong answer is if you said there was only a single right answer. Prepare your rotten tomatoes, Ben is about to say something unpopular. The influx of players that are to be expected from 1.0 give us an interesting option. We could theoretically change the vocabulary of the game to be more consistent, reasonable, and generally more helpful to players. Then, as new players join the community, this new language will slowly replace the old. This would help ease communication between all players; veterans and new addicts alike. Consistency will also help polish the experience to the level that players expect from the game. Who should change it? Before Rseding jumps in with some awesome news, I would ask you to have your say in this Google form. It will be fun to see what you come up with, and I will publish the results in a few weeks.
Hello, let me show you another dose of things we just can't stop ourselves from doing.
Tile transition collisions Klonan We first mentioned a change to our tile transition logic back in FFF-199, and not long after in FFF-214. These two posts focused more on the visual side, and how it makes the game terrain look so much better. In short, the tile transition logic overlays an additional sprite over adjacent tiles, so that where the two tiles meet has a much more natural look. Left: Tile transitions on; Right: Tile transitions off. So while the looks were taken care of, we also had to deal with the 'feel' of the tiles. The easiest example of this is the 1x1 landfill 'stepping stones'. It really looks like you should be able to walk/drive across the 1 tile of water. So we added in an additional layer of collision checks, which will consider the transitions when performing the logic of what can go where. Now some of the cheesier among you will know that biters don't know how to get across these 1 tile gaps. That is because simply we never enabled the biters to use this collision check logic. One reason is that more checks means more UPS usage for the biter pathfinding, another is that we didn't think it was necessary. However it was available in the engine, and any mod could enable it if they want. That is exactly what I did with my Mining drones mod. Initially this seemed to work, and I thought it might make them walk around lakes a bit more naturally (like the player character does). However quickly I noticed that people were reporting on the forum that the game was crashing with the mod installed. I quickly reverted the change to my mod and we started looking into it. It turns out that the new abstract pathfinder we added for better unit pathfinding (FFF-317) was not set up to consider units using this tile transition collision logic. This same crash was happening sometimes without any mods installed, but the case was more difficult to reproduce, so this is a nice situation where mods help us work on issues in the base game. Recently I have been working on another unit heavy mod, Transport drones, and the principle design behind the mod heavily relies on the tile collision logic (the units don't even collide with entities). It turned out to be a really nice test of our new pathfinder, but also highlighted some of the issues that not considering the tile transitions can bring. By not considering the tile transitions, the drone takes an awkward path along the diagonal road. This week Oxyd finished his work on an upgrade to the pathfinder, so we can enable the tile transition collision logic with units. The change is immediately noticeable with the above example. By considering the tile transitions, the drones path much more naturally. With the logic now in place, we are debating whether to enable it for biters or not. We probably won't, it is only a minor change and would have a non-zero performance impact (a rough test puts the worst case at about 5%), but then again it is a fun way to surprise those who thought the 1 tile of water would stop the biters attacking, and it kinda makes sense they can walk over it just as the player can. Well we will see if there are any issues with it in the modded cases before any further consideration. As a bonus fact (this is Factorio facts after all), I spent a bit of time benchmarking some late game Transport drone based factories (screenshot), and found a few nice performance gains.
Blueprint library finishing touches kovarex At the time of writing the Friday Facts last week, not all of the planned changes were finished, here is the finalisation, so here we go.
Hello, today we will go over some of the details of Space platforms we couldn't fit into the last FFF, as well as some new features that will tie the whole system together.